Please post bug reports for emphatic v2.0 here, and I'll respond to them as they come up.

With certain very fast and wordy lyrics, the vertical scrolling mode doesn't quite keep up well. At least I think it's not quite behaving the way you want it to behave and it's possible it could do a bit better.

Example: Do the mode "Title Behind" and play Weird Al's "Your Horoscope For Today" using the lyric I just submitted to the database. I just now re-did it with the SYLT plugin so that I could get the milliseconds in there (boy that song really needs those milliseconds).

On the middle bridge ("Now you may find it inconceivable or at the very least a bit unlikely that the relative position of the planets and the stars..."), note how in a couple of places, each line of words creeps unusully slowly up the screen, even though the next line is fast approaching. This makes the screen have to jump when the line arrives, and you can't quite see the line properly, at least not if you're trying to sing along.

I'd rather have it speed up the scrolling to try to keep up, rather than slowing down and jumping.

Yes, I realize this song is a torture test...

Got an odd bug, not sure if this is in LrcDB or in the SYLT plugin or where I should be reporting this (not sure if you want bugs for those apps in this thread or not), but...

I have a song (Glory of the 80's by Tori Amos) that plays fine and looks right when played in emphatic.

I opened the song in the SYLT plugin and hit "Submit to LRCDB". It worked, but some lines are missing when I view the song on LRCDB. I re-open the file in the SYLT plugin and notice that those lines don't have a timestamp in front of them. Odd, I was sure I tagged this lyric right back in the old days with the old LyrIE plugin.

In fact, the missing lines appear exactly on cue when I play the song on the car player, as if they have proper timestamps on them. But something about the parser in the SYLT plugin makes the timestamp disappear from the lines when I open the song.

There were a lot of single and double quotes in the song, does quote parsing have anything to do with it?

It looked like this when I opened it in the SYLT plugin (bolded line is an example of a missing one):

[00:32.000]
[00:34.000]I had the Story of O in my bucket seat,
[00:38.000]in my wanna be Mustang,
[00:40.000]auditioning for reptiles in their
[00:44.000]Raquel Welch campaign.
[00:46.000]In the glories of the 80's you said
[00:49.000]"I'm not afraid to die",
[00:51.000]I said, "I don't find that remotely funny,
even on this space cake high."
[00:55.000]
[00:57.000]And then when it all seemed clear,
[01:03.000]just then you go and disappear.
[01:08.000]Disappear
[01:12.000]Disappear

In fact, the more I look at it, the more I think it's got something to do with quote parsing, because another missing line has a similar arrangement of quotes:

[01:28.000]in the glories of the 80's you said,
[01:31.000]"the end is nothing to fear".
[01:34.000]I said, "blow the end now baby
who do I gotta shag, to get outta here?"
[01:36.000]
[01:40.000]And then when it all seemed clear,
[01:45.000]just then you go and disappear.

Let me see if any of the other songs that might have quotes arranged the same way are like that. I can think of at least a few I submitted tonight which possibly might have the same problem...

Ah, nope. I'll bet it has to do with tagging blank lines (so the instrumental areas scroll properly) and leaving blank lines in the lyric:

[00:41.000]"Time to race," she said,
[00:46.000]"race the downhill."
[00:52.000]Behind crystalline irises, loons can dive
Where the world bleeds white
[01:01.000]
[01:06.000]Just keep your eyes on her

Great, so now I just submitted about 18 songs to LrcDB today and I'll bet most of them had this problem. Argh...

That one is for me!


I noticed that too. It comes from the non-timestamped lines between "paragraphs".

I use vbid3lib to get the frames from mp3. If I ask for a SYLT frame and none is find in the song, it starts looking for id3v1 (lyrics3) data. There's no way for me to tell if the data returned came from a valid SYLT frame or Lyrics3. I parse the data that is returned as if it was from a SYLT frame. The odd thing is that with empty lines, id3lib seems to mess up the order of tag/crlf in Lyrics3.


For the moment, you should verify lyrics before using/submitting them. The only permanent way out of this will be for me to write my own code to read the mp3. This way, I'll be able to control how/what data is returned from each request.

I was reading the whole id3v2 doc at the moment... When I implemented Artist/Album/Title read in 1.1, it slowed down the reading of the mp3 and that's what convinced me to try to do it myself. This will be another good reason.


Sorry for the bug. This should be fixed in next version. It'll be a big chunk though, so it may take a week or two... I'm still learning ;-)

In case anyone is interested, Patrick is working on a fix for the "Missing lines" problem and should have another release soon.

I would like to publicly apologize to TonyC for briefly accusing his LrcTool code of being the culprit during the period when Patrick was debugging the problem. In fact, the root of the problem was ID3Lib's Lyrics3-to-SYLT conversion... Which Patrick is now working around.

No, I'm just running emphatic, and I think RC is set to 32.

Well, not happening here on either my v2 or v3 player, but my v2 one only has 20 test tracks on it right now, so our setups aren't 100% the same. *shrug*

Since v2.01 is out, I'm locking this thread in favor of a version-specific one. The wish thread will remain open for new feature requests.